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System And Method For Erasing A Data Frames Queue On A Mobile Device 

CROSS-REFERENCE TO RELATED APPLICATION 
This application claims priority from and is related to the following prior application: 
5 "Erasing Data Frames Queue On A Mobile Device," United States Provisional Application No. 
60/404,913, filed August 22, 2002. This prior application, including the entire written 
description and drawing figures, is hereby incorporated into the present application by reference. 

FIELD 

10 The technology described in this patent document relates generally to the field of 

connection management in wireless networks. More particularly, the patent document describes 
a system and method for erasing a data frames queue in a mobile device, which is particularly 
well-suited for General Packet Radio Service (GPRS) connection management. 

15 BACKGROUND 

When a mobile device connected to a wireless GPRS network goes out of coverage, the 
device typically does not immediately disconnect from the network. Rather, a typical mobile 
device will queue outgoing data frames for transmission one coverage is re-established. These 
queued data frames may include user data, network control data (e.g., a GPRS attach request, a 

20 Packet Data Protocol (PDP) context request, etc.), or other information. 

If the initial network connection is still valid when coverage is re-established, then the 
queued data frames may be transmitted from the mobile device to the network with no 
interruption in communication. However, if the initial network connection is no longer valid 
once the mobile device comes back into coverage, then the mobile device may send invalid or 
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out-of-context queued data frames to the network. This situation may occur, for example, if the 
mobile device terminates the network connection while out of coverage. If invalid or out-of- 
context data frames are processed by the network, then synchronization may be lost between the 
mobile device and the network, resulting in an interruption in communication. 

5 

SUMMARY 

In accordance with the teachings described herein, systems and methods are provided for 
managing communications between a mobile device and a wireless network. The mobile device 
may include a memory subsystem, a communication subsystem and a processing subsystem. 

10 The communication subsystem may be operable to transmit and receive data over the wireless 
network. The processing subsystem may be coupled to the memory subsystem and the 
communication subsystem and may be operable to store and retrieve data in the memory 
subsystem, to execute instructions stored in the memory subsystem, and to cause the 
communication subsystem to transmit and receive data over the wireless network. 

15 The mobile device may further include an executable network management program 

stored in the memory subsystem. The network management program may cause the mobile 
device to terminate a first communication link with the wireless network while in an out-of- 
coverage state, and queue data in the mobile device relating to the first communication link. The 
network management program may further cause the mobile device to receive instructions to 

20 establish a second communication link between the mobile device and the wireless network, and 
delete the queued data relating to the first communication link. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a block diagram showing mobile devices in and out of network coverage; 
Fig. 2 is a diagram of an example data frame structure; 

Fig. 3 is a flow diagram illustrating an example method for erasing invalid or out-of- 
5 context data frames from the mobile device queue; 

Fig. 4 is a block diagram of an example mobile device; 

Fig. 5 is a state diagram illustrating example states of a GPRS mobile device; 

Fig. 6 is a diagram illustrating a PDP Context Activation Request initiated by a mobile 

device; 

10 Fig. 7 is a diagram illustrating a PDP Context Deactivation Request initiated by a mobile 

device; and 

Fig. 8 is a diagram illustrating a GPRS Detach initiated by a mobile device. 

DETAILED DESCRIPTION 

15 With reference now to the drawing figures, Fig. 1 is a block diagram showing mobile 

devices in and out of network coverage. More particularly, Fig. 1 illustrates three (3) mobile 
devices 120, 121, 123 located within a coverage area 100 for a network base station 1 10, one (1) 
mobile device 122 located outside of the coverage area 100, and one (1) mobile device 124 
located in a fringe coverage area near the border of the base station coverage area 100. The 

20 mobile devices 120, 121, 123 within the coverage area 100 may communicate with the base 
station 110. The mobile device 124 on the border of the coverage area 100 may receive 
intermittent coverage as it moves in and out of the coverage area 100. 
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In addition, Fig. 1 also illustrates different network connection states 130-132 between 
the mobile devices and the base station. The connection state 130 between mobile device 120 
and the base station 110 represents a full packet data protocol (PDP) context with the wireless 
network, which enables the mobile device 120 to exchange packet data units (PDUs) with the 
5 wireless network. The connection states 131, 132 between the base station 110 and mobile 
devices 121 and 124 illustrate a GPRS Mobile Mobility (MM) Context, in which a PDP context 
has not been initiated, and the mobile device 121, 124 cannot exchange PDUs with the wireless 
network. Mobile device 124 may be able to maintain the GPRS MM context 132 despite its 
intermittent network coverage. Mobile device 123, although within the coverage area 100, is not 

10 connected to the network. Mobile device 122 is out of coverage, and therefore does not have a 
connection to the network. 

Fig. 2 is a block diagram of an example link logic control (LLC) data frame structure 200 
that may be used to transfer PDUs between a mobile device and a GPRS network. The LLC 
frame 200 includes an address field 202, a control field 204, an information field 206, and a 

15 frame check sequence (FCS) 208. Additional detail regarding the LLC data frame structure 200 
is included in the Logic Link Control (LLC) layer specification GSM 04.64, which* is 
incorporated into the present application by reference. 

The address field 202 includes a protocol discriminator (PD) bit 210, a 
command/response (CR) bit 212, and a service access point identifier (SAPI) 214. The PD bit 

20 210 identifies the protocol of the frame structure 200. In an LLC data frame structure 200, the 
PD bit 210 is typically set to 0, and a frame with the PD bit 210 set to 1 is typically invalid. The 
CR bit 212 identifies whether the frame 200 is a command or a response. If the device sends a 
command to the network, then the CR bit 212 is typically set to 0. If the network sends a 
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command to the device, then the CR bit 212 is typically set to L The SAPI 214 identifies the 
data link controller identifier for which a frame is intended. 

The control field 204 identifies the type of frame and typically consists of between one 
and three octets. Examples of control field formats include confirmed information transfer, 
5 supervisory functions, and unnumbered format. A confirmed information transfer format may be 
used to transmit end-user data between two devices. A supervisory format may be used to 
perform control functions, such as acknowledging transmitted frames. An unnumbered format 
may be used for control purposes, such as link initialization, link disconnection, and other link 
control functions. 

10 Typically, LLC frames 200 include an information field 206 which may contain various 

commands and responses. The information field 206 is typically only included, however, if the 
format of the control field 204 is an information transfer format. 

The frame check sequence (FCS) field 208 may include a 24-bit cyclic redundancy check 
(CRC) code, which may be used to detect bit errors in the frame header and information fields. 

15 Fig. 3 is a flow diagram illustrating an example method for erasing invalid or out-of- 

context data frames from the mobile device queue. The method shown in Fig. 3 may, for 
example, be performed by a network management program executed on a mobile device. 

In step 300, a mobile device is connected to a wireless network with a GPRS MM 
context. In step 302, the mobile device goes out of network coverage. While out of coverage, in 

20 step 304, the method determines whether to terminate the existing GPRS MM context. If the 
GPRS MM context is not terminated, then the method returns to step 302 and the device holds its 
current state. If the GPRS MM context is terminated, however, then the method proceeds to step 
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306. The decision to terminate or not to terminate the GPRS MM context may, for example, be 
made by a mobile device user, a software timer, or some other suitable means. 

In step 306, the device queues outgoing data in a local data store while waiting for 
coverage to be restored. For example, the device may queue outgoing control data (e.g., a GPRS 
5 Detach or PDP context deactivation request), user data, or other outgoing data relating to the 
GPRS MM Context to be terminated. 

Before coverage is restored, the method determines in step 308 whether to initiate a new 
GPRS MM context. If the method determines that a new GPRS MM Context should be initiated, 
then the method proceeds to step 310. Otherwise, if a new GPRS MM context is not initiated, 

10 then the method remains at step 308. At step 310, any data still in the queue relating to the first 
GPRS MM Context, such as pre-existing user data or recently added control data (e.g., GPRS 
Detach or PDP deactivation data), is deleted to eliminate confusion between the network and the 
mobile device when the mobile device re-enters network coverage. After deleting the existing 
queued data, new outgoing data, such as a GPRS Attach, is queued in memory at step 312. 

15 Fig. 4 is a block diagram of an example mobile device 400 that may be used with the 

systems and methods described herein. The mobile device 400 is preferably a two-way 
communication device having voice and data communication capabilities: The mobile device 
preferably has the capability to communicate with other computer systems on the Internet. 
Depending on the functionality provided by the device, the device may be referred to as a data 

20 messaging device, a two-way pager, a cellular telephone with data messaging capabilities, a 
wireless Internet appliance, a data communication device, or other device type. 

If the mobile device 400 is enabled for two-way communications, then it may incorporate 
a communication subsystem 411, including both a receiver 412 and a transmitter 414, as well as 
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associated components such as one or more antenna elements 416 and 418, local oscillators 
(LOs) 413, and a processing module such as a digital signal processor (DSP) 420. It should be 
understood, however, that the particular design of the communication subsystem 411 is 
dependent upon the communication network in which the device is intended to operate. For 
5 example, a mobile device 400 may include a communication subsystem 41 1 designed to operate 
within the Mobitex™ mobile communication system, the DataTAC™ mobile communication 
system, and/or a GPRS network. 

Network access requirements may also vary depending upon the type of network 419. 
For example, in the Mobitex and DataTAC networks, mobile devices 400 are registered on the 

10 network using a unique identification number associated with each mobile device. In GPRS 
networks, however, network access is associated with a subscriber or user of a mobile device 
400. A GPRS mobile device therefore requires a subscriber identity module, commonly referred 
to as a SIM card, in order to operate on a GPRS network. The SIM card may store 
configurations, identification and subscriber related information 450. The O-PPLMN, the U- 

15 PPLMN and the forbidden PLMN (FPLMN) 450 are initially received from the SIM card. 
Reference to the PPLMN hereinafter will generally apply to both the O-PPLMN and U-PPLMN. 

When required network registration or activation procedures have been completed, a 
mobile device 400 may send and receive communication signals over the network 419. Signals 
received by the antenna 416 through a communication network 419 are input to the receiver 412, 

20 which may perform typical receiver functions, such as signal amplification, frequency down 
conversion, filtering, channel selection and the like, and in the example system shown in Fig. 4, 
analog to digital conversion. Analog to digital conversion of a received signal allows more 
complex communication functions (e.g., demodulation and decoding) to be performed in the 
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DSP 420. Similarly, signals to be transmitted by the mobile device are processed (e.g., 
modulated and encoded) by the DSP 420 and input to the transmitter 414 for digital to analog 
conversion, frequency up conversion, filtering, amplification and transmission over the 
communication network 419 via the antenna 418. 
5 The DSP 420 may also provide receiver and transmitter control. For example, the gains 

applied to communication signals in the receiver 412 and transmitter 414 may be adaptively 
controlled through automatic gain control algorithms implemented in the DSP 420. 

The mobile device 400 preferably includes a microprocessor 438, which controls the 
overall operation of the device. Communication functions, such as data and voice 

10 communications, are performed through the communication subsystem 411. The microprocessor 
438 also interacts with further device subsystems, such as the display 422, flash memory 424, 
random access memory (RAM) 426, auxiliary input/output (I/O) subsystems 428, serial port 430, 
keyboard 432, speaker 434, microphone 436, short-range communications subsystem 440 and 
any other device subsystems generally designated as 442. For example, the microprocessor 438 

15 may queue outgoing transmissions in the RAM 426 while the mobile device 400 is out-of- 
coverage with the wireless network 419. The microprocessor 438 may also execute a software 
application to perform mobile mobility (MM) and other network management functions, such as 
those described above with reference to Fig. 3. 

Some of the subsystems shown in Fig. 4 perform communication-related functions, 

20 whereas other subsystems may provide "resident" or on-device functions. In addition, some 
subsystems, such as the keyboard 432 and the display 422, may be used for both communication- 
related functions and device-resident functions. 
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Operating system software used by the microprocessor 438 may be stored in a persistent 
store such as flash memory 424, but could also be stored in a read only memory (ROM) or 
similar storage element. The operating system, specific device applications, or parts thereof, 
may be temporarily loaded into a volatile store such as RAM 426. Received communication 
5 signals and queued outgoing communication signals may also be stored to RAM 426. 

As shown, the flash memory 424 can be segregated into different areas for computer 
programs and program data storage 451. These different PIM storage types indicate that each 
program can allocate a portion of flash memory 424 for their own database requirements. The 
microprocessor 438, in addition to its operating system functions, preferably enables execution 

10 of software applications on the mobile device. A predetermined set of applications that control 
basic operations, for example data and voice communication applications, may be installed on 
the mobile device 400 during manufacturing. A preferred software application may be a 
personal information manager (PIM) application having the ability to organize and manage data 
items relating to the user of the mobile device such as, but not limited to, e-mail, calendar events, 

1 5 voice mails, appointments, and task items. 

One or more memory stores may be available on the mobile device to facilitate storage of 
PIM data items. Such PIM application may have the ability to send and receive data items via 
the wireless network 419. In a preferred embodiment, the PIM data items are seamlessly 
integrated, synchronized and updated, via the wireless network 419, with the mobile device 

20 user's corresponding data items stored or associated with a host computer system. Further 
applications may also be loaded onto the mobile device 400 through the network 419, an 
auxiliary I/O subsystem 428, serial port 430, short-range communications subsystem 440 or any 
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other suitable subsystem 442, and installed by a user in the RAM 426 or a non-volatile store for 
execution by the microprocessor 438. 

In a data communication mode, a received signal such as a text message or web page 
download is processed by the communication subsystem 411 and input to the microprocessor 
5 438, which preferably further processes the received signal for output to the display 422, or 
alternatively to an auxiliary I/O device 428. A user of mobile device 41 1 may also compose data 
items, such as email messages, using the keyboard 432, which is preferably a complete 
alphanumeric keyboard or telephone-type keypad, in conjunction with the display 422 and 
possibly an auxiliary I/O device 428. Such composed items may then be transmitted over a 

1 0 communication network through the communication subsystem 411. 

For voice communications, overall operation of the mobile device 400 is similar, except 
that received signals may be output to a speaker 434 and signals for transmission may be 
generated by a microphone 436. Alternative voice or audio I/O subsystems, such as a voice 
message recording subsystem, may also be implemented on the mobile device 400. Although 

15 voice or audio signal output is preferably accomplished primarily through the speaker 434, the 
display 422 may also be used to provide an indication of the identity of a calling party, the 
duration of a voice call, or other voice call related information for example. 

The serial port 430 may be implemented in a personal digital assistant (PDA)-type 
mobile device for which synchronization with a user's desktop computer may be desirable, but is 

20 an optional device component. Such a port 430 may enable a user to set preferences through an 
external device or software application and may extend the capabilities of the mobile device 400 
by providing information or software downloads to the mobile device 400 by means other than 
via a wireless communication network. This alternate download path may, for example, be used 
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to load an encryption key onto the device through a direct and thus reliable and trusted 
connection to enable secure device communication. 

A short-range communications subsystem 440 may provide communication between the 
mobile device 400 and different systems or devices, which need not necessarily be similar 
5 devices. For example, the subsystem 440 may include an infrared device and associated circuits 
and components or a BluetoothTM communication module to provide for communication with 
similarly-enabled systems and devices. 

Fig. 5 is a state diagram illustrating three mobility management (MM) states of a GPRS 
mobile device, the IDLE state 510, the STANDBY state 520, and the READY state 530. In the 

10 IDLE state 510, the mobile device has not attached to a GPRS Support Node (SGSN) and is 
therefore not monitored by the GPRS network. The only receiver infrastructure required to be 
supported in the IDLE state 510 is the storage of the mobile device's records in the home 
location register (HLR). In the STANDBY state 520, the mobile device is attached and is 
actively monitored by the GPRS network, but no data transmission occurs. That is, network 

15 resources are used in the STANDBY state 520 for mobility management so that the network 
knows the location of the mobile station. In the READY state 530, the mobile device is attached 
and data may be transferred between the mobile device and the GPRS network. 

A mobile device may transition between states with the occurrence of certain mobility 
management events, illustrated by the arrows in Fig. 5. To transition from the IDLE state 510 to 

20 the READY state 530, the mobile device may initiate a GPRS Attach 511 message. If the 
mobile device successfully attaches to the network, then the mobile device will be monitored by 
the network through the Serving GPRS Support Node (SGSN). If the GPRS Attach 511 fails, 
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however, then the mobile device remains in the IDLE state 510. Following a successful GPRS 
Attach 551, a Mobile Mobility (MM) context is active at the mobile device and the SGSN. 

In the READY state 530, a Packet Data Protocol (PDP) context may be activated, which 
allows the user of the mobile device to establish a packet data session with the associated packet 
5 data networks (PDNs). In particular, the activation of a PDP context will associate a PDN 
address within the mobile device and Gateway GPRS Support Node (GGSN). Within a valid 
PDP context, Protocol Data Units (PDUs) may be transferred between the mobile device and the 
network. 

When the transmission of PDUs is complete, a Ready Timer is started, which typically 
10 has an expiration time of 32 seconds, but may be set to other values. After the expiration of the 
ready timer 532, the mobile device changes from the READY state 530 to the STANDBY state 
520. The mobile device can also be forced into the STANDBY state 520, without regard to the 
status of the Ready Timer and the transmission of PDUs, if the mobile device receives a Force to 
Standby Signal from the SGSN. 
15 To transition from the STANDBY state 520 back into to the READY state 530, a PDU 

transmission 531 may be required, either from the wireless network or the mobile device. When 
there are PDUs to transmit/receive, the mobile device and SGSN will enter the READY state 530 
and activate a PDP context. 

To transition from a STANDBY state 520 to an IDLE state 510, an explicit GPRS Detach 
20 or Cancel Location 522 may be required. This change of state removes both the PDP and MM 
contexts. 
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To transmission from a READY state 530 to an IDLE state 510, a GPRS Detach or 
Cancel Location 512 may be required. This change of state also removes both PDP and MM 
contexts. 

A PDP Context may be initiated by either the mobile device or the network while the 
5 mobile device is in the STANDBY or READY state. The PDP Context contains the mapping 
and routing information necessary to transfer packet data units (PDUs) between a mobile and the 
Gateway GPRS Support Node (GGSN) (or vice versa). During the PDP context activation 
procedure a number of working parameters may be negotiated, such as the allocation of a PDP 
address, the provision of an access point name (APN) to an external network and GGSN, and the 

10 provision of the quality of service (QoS). The QoS parameter includes the negotiation of the 
priority required for the packet transfer, the reliability of the connection in terms of possible loss 
of data, the delay within the network, and the required throughput, or amount of data per second. 

Fig. 6 is a diagram illustrating a PDP Context Activation Request initiated by a mobile 
device. The mobile device 600 sends an Activate PDP Context Request 601 to the Serving 

15 GPRS Support Node (SGSN) 620 over a wireless link. After this request, any necessary Security 
Functions 602 are negotiated between the SGSN 620 and the mobile device 600. The SGSN 620 
then sends a Create PDP Context Request 603 to the Gateway GPRS Support Node (GGSN) 630. 
The GGSN 630 responds by sending a Create PDP Context Response 604 to the SGSN 620. The 
SGSN 620 then sends an Activate PDP Context Accept 605 to the mobile device 600. 

20 A GPRS attach is performed when a mobile device indicates its presence to the network 

for the purpose of using the services provided by that network. Depending upon the mode of the 
network, this may be an IMSI (international mobile subscriber identity) attach for GSM circuit- 
switched services, a GPRS attach, or a combined IMSI/GPRS attach. (IMSI is a unique 
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identifier for GSM networks that is associated with the SIM card of the mobile device. ) The 
GPRS attach is made to the SGSN and includes information such as the mobile device's 
identification (MSI or P-TMSI (packet-TMSI)) and the mobile device's position (indicated by 
the routing area identification). Upon receipt of this information, the SGSN authenticates the 
5 mobile device and informs the Home Location Register (HLR) of the mobile device's position. 

When a GPRS attach is performed, the SGSN allocates a P-TMSI to the mobile station, 
which is used by the mobile station to derive another value known as the TLLL The TLLI may 
be derived from at least four sources. One, a local TLLI may be derived, using the P-TMSI from 
the SGSN, which is only valid in the routing area associated with the P-TMSI. Two, a Foreign 

10 TLLI may be derived from a P-TMSI allocated in another routing area. Three, a Random TLLI 
may be chosen by the mobile device in the absence of a valid P-TMSI in order to determine a 
TLLI value. Four, an auxiliary TLLI may be used for anonymous access. 

At any time, the network through the SGSN may issue a net P-TMSI, and as a result the 
mobile device should generate a new TLLI. The new TLLI is used to ensure a logical link 

15 between the mobile device and SGSN. 

Fig. 7 is a diagram illustrating a PDP Context Deactivation Request initiated by a mobile 
device 710. The mobile device 710 sends a Deactivate PDP Context Request 701 to the SGSN 
720. Any necessary security functions 702 are then negotiated between the mobile device 710 
and SGSN 720. Once the security functions 702 are negotiated, the SGSN 720 sends a Delete 

20 PDP Context Request 703 to the GGSN 730. If successful, the GGSN 730 responds to the 
SGSN 720 with a Delete PDP Context Response 704. The SGSN 720 then sends a Deactivate 
PDP Context Accept 705 to the mobile device 710. 
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Fig. 8 is a diagram illustrating a GPRS Detach initiated by a mobile device 810. The 
mobile device 810 sends a GPRS Detach Request 801 over a wireless network to the SGSN 820. 
The GPRS Detach request 801 may contain information, such as the GPRS Detach type 
indicating whether the IMSI connection should also be severed, and a Switch Off flag indicating 
5 whether the mobile station 810 is being powered down. If there is an active PDP context 
between the mobile device 810 and the GGSN 830, then the SGSN 820 sends a Delete PDP 
Context Request 802 to the GGSN 830. If successful, the GGSN 830 replies to the SGSN 820 
with a Delete PDP Context Response 803. If the GPRS Detach type indicates that the IMSI 
connection should be severed, then a GPRS Detach Indication 804 is sent from the SGSN 820 to 

10 the Mobile Switching Center (MSG)/ Virtual Location Register (VLR) 840. If the GPRS Detach 
Type indicates that only the GPRS connection is to be severed, maintaining the IMSI connection, 
then the SGSN 820 sends a GPRS Detach Indication 805 instead of the GPRS Detach Indication 
804. Then, if the Switch Off flag sent along with the GPRS Detach request indicates that the 
mobile device 810 is remaining powered on, then the SGSN 820 sends a Detach Accept 806 to 

1 5 the mobile station 810. 

This written description uses examples to disclose the invention, including the best mode, 
and also to enable a person skilled in the art to make and use the invention. The patentable scope 
of the invention may include other examples that occur to those skilled in the art. 
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